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Abstract. The Tor network relies on volunteer relay operators for re- 
lay bandwidth, which may limit its growth and scaling potential. We 
propose an incentive scheme for Tor relying on two novel concepts. We 
introduce TorCoin, an "altcoin" that uses the Bitcoin protocol to re- 
ward relays for contributing bandwidth. Relays "mine" TorCoins, then 
sell them for cash on any existing altcoin exchange. To verify that a given 
TorCoin represents actual bandwidth transferred, we introduce TorPath, 
a decentralized protocol for forming Tor circuits such that each circuit is 
privately- addressable but publicly verifiable. Each circuit's participants 
may then collectively mine a limited number of TorCoins, in proportion 
to the end-to-end transmission goodput they measure on that circuit. 



1 Introduction 

The Tor network suffers from slow speeds, due to a shortage of relay nodes 
from volunteers. This is a well studied problem, but despite many attempts, there 
is not yet a widely-adopted mechanism for compensating relay operators while 
retaining anonymity of clients [1-7]. This paper outlines one possible solution, 
embodying two complementary novel ideas: 

1. TorCoin is an alternative cryptocurrency, or altcoin, based on the Bitcoin 
protocol [8]. Unlike Bitcoin, its proof-of-work scheme is based on bandwidth 
rather than computation. To "mine" a TorCoin, a relay transfers bandwidth 
over the Tor network. Since relays can sell TorCoin on any existing altcoin 
exchange, TorCoin effectively compensates them for contributing bandwidth 
to the network, and does not require clients to pay for access to it. 

2. TorPath is a secure bandwidth measurement mechanism that utilizes decen- 
tralized groups of "Assignment Servers," extending Tor's existing "Directory 
Servers," to assign each client a Tor circuit that is publicly verifiable, but pri- 
vately addressable. This mechanism allows TorPath to "sign" newly-minted 
TorCoins, so that anyone can verify a TorCoin by checking the blockchain. 



2 Motivation and Related Work 



Solving the problem of compensating Tor relays is attractive in that it might 
immediately improve the scalability of the Tor network. Prior research has not 
arrived at a fully satisfactory design for such an incentive scheme, however. We 
now outline what we believe to be the key requirements for such a scheme, while 
noting that more extensive discussion of these requirements and the architectural 
tradeoffs they entail is available elsewhere [9]. 

2.1 Requirements of an Incentive System 

An incentive system must retain anonymity but verifiably measure bandwidth 
and reliably distribute payment to the nodes that provide it. The system must be 
resilient to adversaries attempting to identify clients or fake bandwidth transfer. 

Preserving Anonymity: Among Tor's existing properties that TorCoin must 
preserve, no Tor client can recognize another, and no relay can identify the source 
and destination of any packet flow. Proposed incentive schemes like Tortoise [5] 
and Gold Star [3] may compromise clients' anonymity by allowing their traffic to 
be identified [6]. In a proportionally differentiated service [10,11] like LIRA [6], 
a speed-monitoring adversary can potentially partition the anonymity set into 
clients that are paying for higher speeds, thus reducing anonymity. TorCoin 
should at least preserve the anonymity of the current Tor protocol, and ideally 
improve on it by attracting more clients and relays. 

Verifiable Bandwidth Accounting: TorCoin needs to measure bandwidth in 
such a way that anyone can verify its measurements. Optimally, it will not require 
self-reporting or centralized servers, unlike EigenSpeed [12] or Opportunistic 
Bandwidth Monitoring [13]. The system should be robust to attackers or groups 
of attackers colluding to misreport bandwidth measurements, and the entire 
network should agree on all measurements. Rather than relying on reported 
network speeds, TorCoin uses an onion-hashing scheme to push bandwidth probe 
packets through Tor circuits to measure their end-to-end throughput. 

Anonymous Payment Distribution: Once TorCoin measures the bandwidth 
a given relay has contributed to the Tor network, TorCoin must distribute pay- 
ment to that relay in a way that preserves anonymity. Specifically, no one should 
be able to associate a bandwidth payment or measurement with a specific relay. 
Since TorCoin also requires verifiable accounting, the problem becomes how to 
verify bandwidth without identifying its provider. 

Reliable Transaction Storage: TorCoin must store sufficient records of previ- 
ous payments to avoid rewarding a relay twice for the same bandwidth transfer. 
Prior incentive schemes like LIRA [6] use a trusted central bank to assign coins 
and track spending, making the incentive scheme dependent on the central au- 
thority. TorCoin avoids relying on a central authority by using the Bitcoin pro- 
tocol's distributed ledger to track transactions and avoid double spending [14]. 

Incremental Deployment: To simplify deployability, TorCoin should require 
minimal changes to the Tor codebase, and should not significantly increase la- 
tency of requests. A good incentive scheme should also be scalable to accommo- 
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Fig. 1. High level TorCoin system architecture for clients and relays. A TorPath Client 
assigns Tor circuits to clients via the TorPath protocol, described in the next section. A 
TorCoin Miner mines TorCoins and stores them in a TorCoin Wallet Each Tor Client 
and Tor Relay operates as usual, but on circuits assigned via the TorPath protocol. 



date a large number of users and relays operating concurrently. TorCoin pursues 
deployability and scalability through its decentralized structure and small trans- 
action overheads supported by existing technologies such as Bitcoin. 



2.2 Key Technical Challenges 

To illustrate the key challenge this paper addresses, we envision a naive bandwidth- 
measurement scheme using blinded cryptographic tokens to signify bandwidth 
transfer. Suppose in this scheme, a client is able to give each relay a token for a 
given amount of bandwidth the relay provides. Relays are then able to convert 
these client-signed tokens into some form of currency. Such a scheme would be 
vulnerable to colluding groups of clients and relays, however, who can simply 
sign each other's transfer tokens without actually transferring any bandwidth. 

We address this challenge via the TorPath scheme described below. TorPath 
restricts clients' ability to choose their own path, ensuring that most paths in- 
clude at least one non-colluding participant (the client or at least one of the 
three relays). Assignment servers bundle large groups of clients and relays into 
groups that collectively choose paths. Even in the relatively rare event that a 
path constructed this way consists entirely of colluding clients and relays, an 
upper bound on the number of coins each path can mint rate-limits potential 
loss to these few, probabilistically rare, entirely- colluding paths. 



3 TorCoin Architecture 



The TorCoin architecture consists of two protocols, TorCoin and TorPath. In 
brief, the TorCoin protocol is a Bitcoin variant that mines coins, while TorPath 
protocol assigns a circuit (entry, middle, and exit servers) to each client, thereby 
"authorizing" the minting of Tor Coins through verifiable proof-of-bandwidth. 

TorCoin runs as a standalone service, requiring little modification to the 
Tor or Bitcoin codebase. Tor clients and relays operate as usual, except clients 
receive circuit assignments from assignment servers^ instead of choosing relays 
arbitrarily from the Tor directory. Separately, a TorCoin Miner on each machine 
mines TorCoins by monitoring the throughput of the local Tor TLS tunnel, and 
communicating with its circuit neighbors via the TorCoin algorithm. 

Figure 1 shows a basic overview of this architecture. 

3.1 Adversary Model 

We are primarily concerned here with an adversary who wishes to obtain Tor- 
Coins without contributing useful bandwidth to the Tor network. We assume 
the adversary is able to control a number of clients and relays. We assume that 
malicious clients and relays know about each other and are able to collude. We 
also assume that the adversary is able to control a minority of assignment servers 
on the network, and that other servers are honest-but-curious. 

3.2 The TorPath Protocol 

The TorPath protocol assigns Tor circuits to clients, replacing the usual Tor 
directory servers with assignment servers^ which form decentralized consensus 
groups. The protocol guarantees that no participant on a circuit can identify all 
other participants, and that each circuit includes a publicly verifiable signature. 
We use TorPath to "sign" each TorCoin, so that anyone can verify a TorCoin's 
validity by comparing its signature to a global history of consensus groups. 

Requirements: The TorPath protocol adheres to the following constraints: 

— No client can generate its own circuit. 

— Every circuit has a unique, publicly-verifiable signature. 

— No client can know the circuit of another client. 

Protocol Outline: The TorPath protocol consists of three sequential steps: 

1. Group Initialization. Assignment servers form a consensus group. Clients 
and available relays provide public keys to join the group. 

2. Verifiable Shuffle. The consensus group performs a decentralized, verifiable 
shuffle of all the public keys, resulting in a circuit assignment for each client. 

3. Path Lookup. The assignment servers publish the result of the shuffle, such 
that each client can identify only its entry relay, and each relay can identify 
only its immediate neighbor(s) in the circuit. 
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Fig. 2. Both relays and clients use onion-encryption to encrypt their own temporary 
public keys with the public keys of all the assignment servers in the group, (a) Each 
client generates one keypair, and sends its public key onion-encrypted to the server, 
(b) Each relay generates multiple keypairs, to support multiple clients and/or circuit 
positions within a consensus group, as instructed by the assignment servers. 



Stage 1 — Group Initialization: A consensus group is formed when a suitable 
quorum of assignment servers come together to assign circuits to recently regis- 
tered clients. For example, if there are 10 assignment servers in the network, we 
might require at least 6 of them to participate in forming each consensus group. 
The assignment servers can modulate the size - and hence anonymity - repre- 
sented by each consensus group, by waiting until there are some configurable 
number n of clients registered before proceeding to the next stage. Different cat- 
egories of consensus groups might use different values of n, allowing clients to 
trade anonymity for wait time. Groups with larger values of n would provide a 
larger anonymity set, at the expense of longer circuit setup times. 
A consensus group forms in three steps: 

1. Each assignment server shares its public key with its group members, 
and broadcasts these public keys to all clients and relays connected to it. 

2. Each cHent connects to one assignment server in the group. The client then 
generates a temporary private and public key pair. The client onion-encrypts 
its temporary public key with the public keys of all assignment servers in the 
group, resulting in a ciphertext that each server can only partially decrypt. 
The client submits this ciphertext to its assignment server. 

3. Each relay can act as an entry, middle, and /or exit relay, and it chooses 
which position (s) to service. The number of available relays available for a 
given position (especially exit relays) may often be less than the number 
of clients in the group needing circuits. To ensure parity between clients 



0 1 2 3 

Client Entry Middle Exit 









Kx K*o 


7-^2/ 


Km 


Kx_ 








K'^ Kl 

Shuffle 

Kl_ Kl 


Kh 












Kl 






_ C 


Kl 




K^^ Kl 


Kh' 








Kl 




TfJ" Kl 


Kh 




^X 


Ri 


Kh 


R2 K% Kx ^3 -^M Kx 


Ri 



Fig. 3. Example matrix shuffle with 5 clients (Ci, C2, C3, Ca and C5) and 4 relays 
(purple, blue, green, red). Each relay Ri generates a number of public keys for each 
circuit position p G E,M,X, as instructed by its assignment server. Here, each client 
Cj is assigned the circuit represented by the j*^ row of the shuffled matrix. 



and relays for each position, each assignment server instructs its relays to 
generate a sufficient number of temporary keys for each position. The relay 
server uses onion-encryption to generate n ciphertexts from n temporary 
public keys. The relay packages these ciphertexts by position and sends them 
to its upstream assignment server. 

Figure 2 illustrates Steps 2 and 3. 

We can represent the temporary keys as an n x 4 matrix M for n clients, 
where each row corresponds to a client and its three relays (see Figure 3). 

Stage 2 — Verifiable Shuffle: The consensus group now shuffles each column 
of the temporary key matrix independently, using a verifiable shuffling algorithm 
such as the Neff Shuffle [15]), and jointly decrypts the shuffled keys. Each row 
in the public result matrix now contains a random 4-tuple of temporary public 
keys representing one circuit: namely the client and the three relays serving that 
client. The assignment servers collectively sign and publish the resulting matrix 
to a public log, accessible by all clients and relays. Although everyone learns 
which four temporary public keys represent the participants of each circuit, the 
verifiable shuffle prevents anyone except a given key's owner from learning which 
participating client or relay owns each of these temporary keys. 
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Table 1. Each participant in a circuit sends its message tuple onion-encrypted to the 
server. {Xjy denotes X encrypted with Y. 



Stage 3 — Path Lookup: In the final step of the algorithm, each client obtains 
the IP address of its entry relay, and each relay obtains the IP address of its 
neighbor (s) on the circuit. The path lookup algorithm ensures that each client 
and relay can obtain only the IP addresses of its neighbors in the circuit. 

Each client encrypts its own IP using the public key of its neighbor. The 
client forms a tuple (public key, encrypted IP) as shown in table 1. The client 
onion-encrypts this tuple and sends it to the assignment servers. Each relay 
follows the same procedure, for every key in the matrix belonging to it. 

The assignment servers shuffle this new list of tuples. Each client and relay 
now finds its neighbors in the matrix by locating the tuples containing the public 
keys it needs. Finally, each participant decrypts the relevant cells using its private 
key, revealing the IP address of its circuit neighbor (s). 

Now all clients in the consensus group have a usable Tor circuit. 

Each circuit formed by a consensus group obtains a unique Circuit Identifier, 
which is an ordered pair consisting of the hash of the matrix M and the row 
number i of the circuit within M: CSi = (Ilash(M), i). This identifier will be 
used in the TorCoin algorithm, together with signatures using the four anony- 
mous temporary public keys comprising that row of M, to prove that TorCoins 
were minted by circuits assigned in consensus groups. 

Security Considerations 

Anonymity: The TorPath protocol guarantees that no single relay knows any 
client's entire circuit. If malicious clients or relays collude, they may be able to 
shrink the anonymity set to the set of honest relays and clients in the consensus 
group. Groups can have varying sizes, however, allowing clients to choose a 
desired balance between anonymity threshold and circuit assignment delay. 

Group Formation: The TorPath protocol's random circuit selection mecha- 
nism prevents colluding clients and relays from deterministically placing them- 
selves in the same circuit, provided not too many participants in each group 
collude. Even if half of the temporary keys in matrix M are held by colluding 



participants, for example, only 1/2^ = 1/16 of the assigned circuits will be com- 
promised and able to mint (a limited number of) Tor Coins without performing 
useful work. We could add further protection against "flash mobs" of collud- 
ing participants by randomizing group assignment across longer time periods, 
instead of using temporal locality as the only grouping criterion. 

Circuit Diversity: TorCoin's Neff shuffle could assign the same relay to one 
circuit in multiple positions: e.g., choose the same physical relay as both entry 
and middle relays. With a reasonable number of participating relays, however, 
it should be extremely unlikely that one relay gets assigned to all three positions 
on the same circuit. In any case, the risk of accidental relay duplication on one 
path should not be substantially greater than the risk Tor users already face of 
randomly placing multiple relays owned by the same operator on a circuit. We 
anticipate that privacy-preserving independence testing techniques [16] could 
be adapted to detect and reject circuits in which the same relay (or operator) 
appears multiple times, but we leave this challenge to future work. 

Persistent Guards: The assignment process above picks three relays afresh 
for each circuit, contrary to Tor's practice of keeping entry relays persistent for 
longer periods. The circuit assignment mechanism could be adapted for per- 
sistent entry relays by combining the first two columns of matrix M into one 
column representing each client together with its choice of entry relay, at the 
cost of slightly increasing the chance of forming all-compromised circuits. 

3.3 TorCoin Mining 

In contrast with Bitcoin's reliance on proof of computation, mining TorCoin 
requires proof of Tor bandwidth transfer. In TorCoin, all participants on a cir- 
cuit assigned by TorPath may collectively mine a limited number of TorCoins, 
incrementally, based on the end-to-end goodput they observe on the circuit. 

Proof of Bandwidth 

1. Each client and relay creates a temporary key R and its hash i?^ = IIash(i?^). 

2. Every m Tor packets, the client sends a tuple (coin#,i?^), where coin# is 
the number of TorCoin packets previously sent in this circuit. 

3. Each relay similarly adds its own temporary hash to the tuple - i?'^, R'j^, 
and R'j^ - and forwards the tuple to the next relay in the circuit. 

4. The exit relay forms the coin commitment blob B = (coin#, i?^, R'^^R'^). 

5. The exit relay then signs the blob B with its temporary public key for this 
circuit to create signature Sx , then opens its commitment to reveal Rx , and 
sends the tuple (5, Sx^Rx) to the middle relay. 

6. Each prior participant in the circuit z, in turn, similarly signs the blob B 
to create ^ adds its signature and opened commitment to the tuple, then 
forwards the tuple to the previous participant in the circuit. 

7. The client forms bandwidth proof P = {B, S^, S^, S^, , Rx, Rm, Re, Rc), 
which anyone may verify against the four temporary public keys in the ap- 
propriate row of matrix M for this circuit. 
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Fig. 4. TorCoin Proof of Bandwidth algorithm. In the upper part of the cycle, the 
relays add their hashes to the tuple. In the lower part, they add their temporary keys 
and sign the tuples. 



8. To check if a TorCoin has been mined, the client checks if the lower-order 
bits of }i8ish{CSi, Rx, Rm^ Re^ Rc) == 0- If so, the client adds the full 
proof-of-bandwidth tuple P to the blockchain to validate the new TorCoin. 
To be valid, the coin# within P must be one greater than that of the last 
TorCoin in the blockchain mined from circuit i, and must be less than the 
well-known limit on the number of TorCoins per assigned circuit. 

9. Finally, the client uses the standard Bitcoin transfer protocol to pay each 
relay in the circuit one third of the mined TorCoin. 



This protocol leaves all information necessary for verifying proof-of-bandwidth 
in the blockchain. Any interested party can verify that the circuit identifier in 
B refers to a valid consensus group by referring to the public log. They can also 
verify that the blob B was signed by the correct participants by verifying the 
signatures against the temporary public in the consensus matrix M, and verify 
that the openings Ri correspond to the corresponding commitments R[ . Because 
the low-order-bit test in step 8 depends only on values secretly committed on the 
"forward path" in steps 2-4, then revealed only on the "return path" in steps 
5-6, no proper subset of the circuit's participants can unilaterally recompute B 
in order to mine TorCoins out of proportion to measured circuit goodput. 

Security Considerations 

Enforcing packet rate: All honest relays and clients enforce the standard 
TorCoin packet rate m. Any relays or clients that deviate from this are reported 
to the assignment servers and the circuit is terminated. 



Enforcing circuits: Relays know their neighbours' IP addresses and wih refuse 
connections from any other IP address. Even if mahcious relays connect to each 
other, they will not be able to sign Tor Coins unless they own a complete circuit. 

Compromised circuits: Colluding clients and attackers needs to control all 
four components of a circuit to mine TorCoins fraudulently. Even if an adversary 
controls up to half the network, only 1/2^ = 1/16 of assigned circuits will be 
fully colluding. In practice, we hope and expect that gaining control of even half 
of all Tor clients and relays would be difficult. To limit the impact of occasional 
colluding circuits, TorCoin also limits the number of coins each circuit can mine. 
This coin number is included in the blockchain, so it is easily verified. The im- 
pact of compromised circuits can be further reduced by ensuring that consensus 
groups expire at regular intervals, requiring clients either to form new circuits 
or cease obtaining new TorCoins from old circuits. 

Bitcoin anonymity: This paper focuses on adapting Bitcoin's mining scheme 
to measure Tor bandwidth instead of computation, and not on Bitcoin's trans- 
action mechanism. Since TorCoin also needs to protect the anonymity of clients 
as they make transactions, we must also account for well-known concerns about 
the limited anonymity the basic Bitcoin transaction protocol offers [17]. Any of 
the recently proposed approaches such as Zerocoin [18], Mixcoin [19], or Coin- 
Shuffle [20] should offer a suitable solution to this orthogonal challenge. 

Deployment: The TorPath network is not backward compatible with the ex- 
isting Tor network, due to the fundamental differences of route assignment and 
access control, which are missing in Tor but necessary for the TorPath and Tor- 
Coin schemes to work. However, any given physical server could run both services 
at the same time. TorCoins are, of course, generated only from TorCoin traffic. 

4 Preliminary Results 

The TorCoin protocol adds a small amount of overhead to Tor traffic. To 
evaluate this overhead, we set up a series of servers using the Python Twisted 
framework [21] to simulate the passing of TorCoin generation and verification 
messages through a set of relays. 

Assuming that the keys, hashes and signatures are all 32 bytes in length, 
the total overhead from one round of successful TorCoin mining (i.e., one entire 
round trip from client through all the relays and back again) results in a total 
TorCoin packet overhead of 1752 bytes. This can be broken down into: 

— The first packet from client to entry relay: 34 bytes. 

— Packet forwarded from entry to middle relay: 66 bytes. 

— Packet forwarded from middle to exit relay: 98 bytes. 

— Packet from from exit to middle relay: 324 bytes. 

— Packet from from middle to entry relay: 518 bytes. 

— Packet from from entry relay to client: 712 bytes 

— Total: 1752 bytes 
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Each round of TorCoin generation and verification happens only after m Tor 
packets have been sent. Each standard Tor cell is 514 bytes long, so each round 
trip on the network requires transmission of 514 * 6 = 3084 bytes. Thus, if 
m > 10, the TorCoin protocol overhead is around 5%. The value of m can be 
calibrated in further experimentation and as needed in order to achieve the sweet- 
spot of transmission efficiency and incentive maximization for relay providers. 

The system might decrease the value of m when load is high, incentivizing 
relay operators to provision more relay bandwidth at such times. 

While the Neff shuffie is complex and requires several communications be- 
tween the servers, we expect the assignment servers will be few (less than 10) 
and well-provisioned, and do not expect the shuffles to be a major bottleneck. 
Since this is a one-time cost of connecting to the network, we hope users will 
accept this setup time if it gives them access to higher-capacity relays. For impa- 
tient users, the TorCoin client could use conventional Tor circuits immediately 
on startup, then transition to TorCoin circuits as they become available. 

5 Conclusions 

We have introduced TorPath, a novel scheme to assign paths to Tor clients 
securely and anonymously. TorPath motivated by the need to verifiably mine 
Tor Coins, a a Bit coin variant based on measured bandwidth over the Tor net- 
work. The TorCoin protocol is robust to malicious relays and clients colluding 
to mint TorCoins without transferring bandwidth. 
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